
AM A A 


NASA— CR-2 00144 





> V*i 

Jr 

4k* 



/r v£ft/z& (sr 



AIAA 95-3574 

Kennedy Space Center Network 
Documentation System 

Mr. William E. Lohne 
I-NET Space Services 
INI-2 

Kennedy Space Center, FL 32899 
and 

Mr. Charles L. Schuerger 
Lockheed Martin Space Operations 
LSO-338, PCC 

Kennedy Space Center, FL 32899 


AIAA 1995 Space Programs and 
Technologies Conference 
September 26-28, 1 995 /Hu ntsville, AL 


For permission to copy or republish, contact the American Institute of Aeronautics and Astronautics 
370 L'Enfant Promenade, S.W., Washington, D.C. 20024 


ABSTRACT 

The Kennedy Space Center Network Documentation 
System (KSC NDS) is being designed and implemented 
by NASA and the KSC contractor organizations to 
provide a means for network tracking, configuration, 
and control. Currently, a variety of host and client 
platforms are in use as a result of each organization 
having established its own network documentation 
system. The solution is to incorporate as many existing 
‘systems’ as possible in the effort to consolidate and 
standardize KSC-wide documentation. 

INTRODUCTION 

The National Aeronautics and Space Administration 
(NASA) and KSC organizations perform the tasks 
necessary to prepare and launch space Shuttles. This 
life cycle begins immediately after an orbiter returns to 
earth and ends the moment it clears the launch tower. 
During that life cycle, there are literally tens of 
thousands of computers used to process information 
vital to a successful launch. Most of these computers 
are networked throughout KSC generating a logistics 
nightmare for the configuration control, tracking and 
planning of the wiring for all these networks. 

HISTORY/PROBLEM STATEMENT 

The interconnection of these computers was initially 
performed without a significant amount of planning or 
coordination. As a matter of fact, each organizations 
implemented required network topologies without the 
benefit of input from other organizations. When it was 
necessaty to connect these networks, representatives 
from each network met to resolve how the 
interconnections were to take place. Documentation 
was not required, so each organization was left on their 
own as to how to represent what had happened. Often, 
because of time constraints, documentation was never 
done, even at the most rudimentary levels, if the network 
appeared to be working. After all, the network 
designers and installers were not documenters! If a 
request was made, the information that could be recalled 
was recorded as hand sketches at best. 

The rapid evolution of large, complex networks at KSC 
added to the problem in that a wide variety of software 
and hardware components was selected to perform the 
design and installation. Each organization ended up 


with different standard computer and network hardware 
to serve individual needs. Today, one can find almost 
every kind of network, configuration, and component 
imaginable. There are users that feel mainframes with 
terminals attached are best, while others are MAC 
supporters and still others use PC systems. In addition, 
it is possible to find various (IBM, Apollo, FDDI) token 
ring configurations, various ethemet configurations 
(e.g., thicknet, thinnet, 10 base T, etc.), and others. 

KSC is a very large, sprawling complex located on the 
east coast of Florida. The north area includes the launch 
pads and the Shuttle refurbishment buildings. The next 
significant area is the Industrial Area that contains KSC 
NASA Headquarters and several supporting buildings. 
In addition, there are numerous peripheral buildings and 
trailers and a number of isolated facilities. Currently, 
connectivity among these facilities is through one of the 
several KSC networks. 

SOLUTIONS 

As a result, the approach in recent years has been to 
make use of existing network information, without 
regard to form, network topology, platform or location. 
Rather than require that each organization modify their 
documentation to meet some newly established 
standard, network documentation personnel have 
elected to design Graphical User Interface (GUI) 
frontends to access existing data. In some cases, this 
has been relatively easy. In others, the data either does 
not exist in electronic form or is in a form that is 
difficult to interface. 

TOOLS 

Many of the organizations recognized the need to 
capture key data along the way and implemented this 
using tools like Microsoft’s EXCEL, Borland’s dBASE 
and dBASE for Windows, Nantucket’s Clipper, 
Microsoft’s FoxPro and Word, and others. Doing this 
allowed at least basic data capture and storage. Others 
developed relational database applications utilizing 
Oracle or Informix. This has resulted in data existing in 
a variety of forms and in a variety of locations. 
Frontends designed today offer the user the capability to 
access data and have it presented in such a manner as to 
appear to come from a single source having a standard 
format. The user only cares that data can be found; it 
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doesn’t make a difference where that data resides nor 
does it matter what form the data takes when stored. 
Furthermore, the user can expect similar information to 
appear the same when in fact this data may exist in 
multiple forms. As an example, cable run data may be 
maintained using a spreadsheet by one organization but 
be contained in a dBASE table by another. The 
information structure is clearly different but the content 
may be the same or very similar. 

Since computer software technology is developing and 
changing rapidly, it is difficult to select a set of tools for 
performing the task. Development of GUI tools means 
that significant improvements are being made daily. 
Also, as each organization is currently using different 
computer platforms, tool selection becomes even more 
complex. Superior tools for one environment might, but 
probably do not, exist for another. For example, while 
Microsoft’s Visual Basic is a strong development tool 
on a PC, there is nothing available for a UNIX 
environment. Macintosh support is minimal also. 
Intergraph Corporation provides a suite of integrated 
development tools that function on both PC and UNIX 
platforms. However, no MAC support is provided. 
What happens is that the developers must be proficient 
in using two or three visual design tools so that each 
frontend can be configured on each platform. Use of X- 
Windows does allow cross-platform operation, but at a 
significant degradation in performance. 

NETWORKS 

Each network evolved to provide a specific need in 
satisfying a requirement. At KSC, there are two 
functions to be satisfied. One has to do with the day-to- 
day administrative activity. These networks are known 
as institutional networks. The other is known as 
mission-critical activity. Mission-critical network data, 
configurations, location of cable runs, etc., are highly 
protected for obvious reasons. Only those personnel 
having a properly established need have detailed 
information concerning these networks. For that reason, 
the institutional networks represent the topic of this 
paper. 

The institutional networks discussed here are the Shuttle 
Operations Data Network (SODN), the KSC Data 
Network (KDN), and the Payload Operations Network 
(PON). Two additional elements of the Kennedy 


Institutional Networks (KIN) are the KSC Metropolitan 
Area Network (KMAN) and the fifth element, the KSC 
Wide Area Network (KWAN), that provides access to 
other NASA Centers and facilities through the Program 
Support Communications Network Interface (PSCNI) 
and the NASA Science Internet (NSI). An overview of 
these networks is shown in Figure 1. Each network is 
configured to meet the requirements that existed at the 
time the network was designed and installed. As such, 
there are significant differences in the structure and 
substance of each network. There are consistent 
properties also. Thinnet, thicknet, phonenet, twisted 
pair and other wiring schemes are used. While the 
predominate physical layer is Ethernet, there are others, 
including Token Ring, etc. 



Figure 1. KSC Network Environment (KNE). 


The KDN includes the Base Operations Network (BON 
and the Document Imaging network. This network is 
not intended for use in any mission-critical operation. 
Various network and transport layer protocols are used 
including TCP/IP, AppleTalk Phase 2, Microsoft 
NetBEUI, etc. 

The PON is also an institutional network and is not used 
for any mission- critical activity. This network provides 
administrative support for the processing of Space 
Shuttle and Expendable Vehicle payloads. About 30 
facilities are provided network inter-connectivity by this 
network. Network and transport layer protocols used 
include TCP/IP, Intergraph XNS, DECnet 5, AppleTalk 
Phase 2 and Microsoft NetBEUI. 

The SODN is a third institutional network and provides 
a wide variety of protocols. The routed network carries 
TCP/IP, AppleTalk, NetBIOS over TCP, XNS, and 
SPX/IPX, as well as many upper layer protocols. WAN 
and LAN intra-facility network connectivity support 
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Ethernet, Token-Ring, broadband, T-Carrier, Fiber 
Optic Inter Repeater Link (FOIRL), and Fiber 
Distributed Data Interface (FDDI) communications 
technologies. 

High-speed backbones are used for data distribution. 
While a high-speed backbone is a critical distribution 
element, premises wiring is critical to local distribution. 
Current premises wiring designs utilize carefully chosen 
media so that future needs can be easily met. In 
addition, designs are such that additions and changes 
can be accommodated without significant impact to 
current operations. 

The Kennedy Metropolitan Area Network (KMAN) is a 
logical network consisting of two physical networks. 
These systems, used in parallel, are configured to allow 
traffic load balancing, and prohibit physical loops 
through the use of Interior Gateway Router Protocol 
(IGRP), a proprietary routing protocol. While there are 
multiple physical connections to the KMAN, by each, to 
the major networks, these connections are all through 
the Kennedy Space Center Isolation (KSCISO) router. 
No host-level or server-level services are directly 
attached to the KMAN. 

There are multiple physical connections to the Kennedy 
Metropolitan Area Network by each of the major 
networks and there is a working group responsible for 
its design and configuration. 

The allowable routed protocols are: 

• IP Suite 

• Novell SPX/IPX 

• DECnet Phase IV 

• OSI ES/IS CLNP 

• SNA 

• XEROX XNS (not Ungerman Bass) 

• AppleTalk Phase II 

The KSC Wide Area Network (KWAN) is the link 
between the Hub routers on PON, KDN, and SODN and 
the KSC Isolation Router, the internal WAN interface. 
The external interface is the link between the KSC 
Isolation Router and the outside world (NSI and 
PSCNI). The router provides routing for IP, DECnet, 
XNS, IPX, and AppleTalk. The router also provides 
Access List security filtering by limiting access to KSC 
for only IP port 25 Simple Mail Transfer Protocol 
(SMTP) and IPX protocol. The IP access for other ports 
is by address access only. Area Mapping is employed 
for DECnet, XNS, AppleTalk, and Novell IPX. The 
three major networks interface through their own 
hubbing systems and are responsible for any further 


filtering or security requirements that may apply to 
their network. 

On the operational side, numerous Network Operating 
Systems (NOS’s) have evolved from the centralized 
mainframe computing environments to a personal 
computer (PC) based distributed system. All NOS’s 
have several common characteristics. These include: 

• Initiate a network communications path 

• Emulate the resident file servers file and data 

structure 

• Send and receive errorless data across the network 

• Terminate communications gracefully 

Generally, NOS’s can be divided into the following two 
different categories: 

• Client/Server technology 

• Peer-to-peer technology 

There are advantages and disadvantages of both 
technologies. In most instances, the number of users 
and the application types determine which technology to 
select. Peer-to-peer networks typically require that the 
user application reside and function on the user’s PC. 
Performance then becomes a function of the user’s PC 
configuration. In this type network, peripherals can be 
shared. The client/server configuration splits an 
application into two parts and assigns the processing of 
each part to the resource best suited to handle it. The 
user workstation or ‘client’ is the front-end and 
manipulates data on the local level. The back-end or 
‘server’ component of the application stores, retrieves, 
processes, and secures data. Many clients can share the 
features of a single server. Client/server architecture is 
designed to optimize network performance by 
attempting to minimize network traffic. In a 
client/server configuration, individual workstations 
communicate with each other through the server. In a 
peer-to-peer NOS, workstations can communicate 
directly. In addition, peer-to-peer NOS’s support most 
of the functions of the client/server NOS. UNIX is also 
a NOS. 

KSC has a variety of LANs as mentioned earlier. In 
addition, several networking NOS’s exist also. The 
networks mentioned earlier utilize the following NOS’s: 

• KDN: Novell NetWare, Microsoft NT Advanced 

Server, AppleTalk 

• PON: LAN Manager, AppleTalk 

• SODN: LAN Manager, IBM LAN Server, 

Microsoft Network (MS-NET), Novell 
NetWare, AppleTalk 

As the computing requirements and user needs grow, 
networking and NOS technology must keep changing 
and improving. 
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NDS APPLICATIONS 

The KSC Network Documentation System makes use of 
all current technologies. The basic configuration 
consists of a Microsoft NT Advanced Server that 
supports several visual software development tools. 
These tools include: 

• Microsoft Visual Basic 

• Borland Paradox for Windows 

• Borland dB ASE for Windows 

• Borland dB ASE for DOS 

• Borland Delphi Client/Server 

• Microsoft SQL Server 

• Microsoft C++ 

• Microsoft SMS 

• Intergraph MicroStation 

• Intergraph dbAccess and related products 

The objective is to provide user friendly GUI access to 
wanted data. This can be accomplished a number of 
ways. Designers at KSC have elected to start with a 
single logon screen followed by a general purpose menu 
containing all available functions. Selective functions 
can be disabled as needed depending on the individual 
user and the allowed access for that user. 

Shown in Figure 2 is one main menu containing typical 
user selections. The following functions can be 
performed as a result of the appropriate menu selection: 

• IP Address Maintenance 

• Available Network Resources 

• Circuit Card Maintenance 

• t-Carrier Maintenance 

• Cable Labels 

• Device Labels 

• Network Drawings and Database 

• Inventory 

• Work Order Preparation 

• Service Requests 

• File Maintenance 

• Network Configuration (Software, Hardware) 

The menu shown in Figure 2 was created using 
Borland’s Paradox for Windows product. Any of the 
other available GUI products could have been used, but 
Paradox represented the easiest platform for this 
application. 

Each button is programmed to perform a predetermined 
function as required at design time. Pressing a button 
launches an application that performs a task described 
by the button’s label. For example, when the user needs 
to make labels for a cable or group of cables, the “Cable 


Labels” button would be selected by placing the mouse 
cursor over the button and pressing the left button. 



Figure 2. User’s Main Menu. 


CA RLE LABEL A P PLICATION 
The code behind the “Cable Labels” button is shown in 
Figure 3. The amount of programming required to 
launch the application consists of one line that tells the 
computer to execute a program located in a pre-defined 
location. The program being launched could be 
anything. In this example, a Paradox form is loaded. 
(Paradox starts an application by loading a form within 
Paradox.) The Screen shown in Figure 4 is the “Cable 
Labels” data maintenance screen. The location of the 
files containing the cable label data could be of almost 
any type: in this case they are dBASE files. 
Furthermore, the location of the database could be on a 
workstation or server physically removed from the user. 
The only requirement is that the data files must be 
shared so that the user can access the data. 



Figure 3. Code to Launch “Cable Labels” Module. 


Normally, the user wants to add label information to the 
database and then print the labels. A number of 
parameters have been programmed into the application 
as shown. Any number of parameters could be 
established and programmed at design time. At KSC, 
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the screen used is somewhat general purpose so that 
most, if not all, the user’s needs are satisfied by this 
single form. If desired, screen layouts could be easily 
modified to meet different needs. 



CABLE ID : BATBlfflllM j LENGTH : f 153 J 

NEA R END ; |HQ3470,J7L3 j j 

FAR END : frQ34/6.0S0476 J j 

CONTACT: {COMPUTER SUPPORT GROuQ ) 
PHONE : fc/-2334 j j 


QUANTITY : pH [ PRINT : m 



Figure 4. A Cable Label Database Maintenance 
Screen. 


print based on the requirement to place a label at least 
every 20 feet along the cable. If the user enters an odd 
number of labels, the application will round up to the 
next full integer. Figure 5 contains the label printout for 
the label shown in Figure 4. 



Figure 5. The Cable Label Format. 


While the function of most of the buttons is self 
explanatory, a more detailed description follows. 

• Add — Add a new cable label record to the 
database. 

• Delete -- Delete the record currently shown. 

• Post -- Post the newly entered record (write the 
record). 

• Output — Select the output type, either labels or a 
listing of all label records contained in the 
database. 

• Edit - Edit the record shown. 

• End Edit — Changes/additions to the current record 
are complete. 

• Sort -- Shown in the inactive state but would sort 
the records in the database as wanted by the user. 

• Search -- Search the database for the record or 
records based on data entered in one or more fields 
on the screen. 

• EXIT — Exit this application and return to the 
main menu. 

An explanation will help to define the “NEAR END” 
and “FAR END” field titles shown in Figure 4. Either 
end of the cable can be termed the near end and by 
default, the other end is the far end. When labels are 
printed, the application is programmed to provide an 
even number of labels. Half will be printed so that they 
can be placed from the near end while the other half are 
placed from the halfway point of the cable to the far end. 
The user enters either the length of the cable in feet or 
the number of labels wanted. The application uses the 
length information to determine the number of labels to 


Once the user has completed the session, pressing the 
EXIT button returns the user to the main menu. The 
newly created cable label information has been placed in 
a file within the prescribed database. Linkages to other 
files in the database are possible through the key cable 
ID field. 

DEVICE LABEL APPLICATION 
A similar requirement is to prepare labels to be placed 
on network equipment. The screen shown in Figure 6 
shows one such way to accomplish the task. Note the 
similarities between the “Cable Labels” and the 
“Device Labels” screens. Colors, button sizes, button 
labels, field titles, etc., are similar in design to minimize 
the visual impact on the user. 
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Figure 6. The Device Label Maintenance Screen. 


IP ADDRESS ASSIGNMENT APPLICATION 
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Another typical network documentation requirement is 
that of assigning and maintaining IP addresses. Most of 
the KSC networks support, and depend on, the TCP/IP 
link. The development team was given the requirement 
that IP addresses were to be assigned automatically and 
by more than one user at a time. This meant that a 
multiuser application had to be written to meet these 
requirements. In many cases, single devices can have 
multiple IP addresses. To accommodate this, a multi- 
file relational database was designed. One file contains 
information concerning devices and the other file 
contains the information about IP addresses for that 
device. 


DEVICE / USER INFORMATION 



ADDRESS INFORMATION 
Port/S krf 8 [P] P*<1 Nmm 1 


Btcpip 


EIMMA*h lu | | | |~n 

TCP/IP M*~ | | 

TCP/IP A*k |l2a [ 15 a |177. Tma~l 
DECE-Nt* 5/M 

D«cNs*N«m 
D tcNotAA* 




Figure 7. IP Address Maintenance Screen. 


At KSC, the problem of maintaining and assigning IP 
addresses generally falls within each established 
network support group. Each organization is assigned a 
network including all subnets. As new networks are 
designed and installed, IP addresses are assigned, often 
manually, from the assigned block of addresses. The 
process of combining everyone’s IP address data into a 
single, shared database is currently in process. Once 
completed, each network administrator will have access 
to the database through the screen shown in Figure 7. 


ADDRESS part of the screen is a view of the related 
device/user address data. The screen contains data 
fields as requested by a number of potential users. Thus 
the application is general purpose. Not all users would 
use every available field. Some fields are mandatory, so 
all users must complete those fields when entering new 
data. 

Where a complete subnet is being assigned to a single 
user (network administrator who will then assign- 
individual IP addresses), the user enters device/user 
information and then selects the S/M hand icon. This 
will automatically assign a block of addresses. This 
generally takes a minute or two while 255 records are 
written to the address file for a single entry in the 
device/user file. 


Network and subnet constraints are initially entered into 
the Building Table shown in Figure 8. These 
parameters are decided at network design time, and the 
table is completed with the information from the design 
layout. Network and subnet design layouts include the 
location information by building and room as required. 
There are times when a network will appear in more 
than one location. Subnets could appear in more than 
one location also. Room data is not always available or 
needed. 



Figure 8. View of Table Controlling IP Address 


Restrictions. 


This application was developed using Microsoft’s 
Visual Basic development environment. The original 
database was dBASE, but it has since been converted to 
Microsoft SQL. A Microsoft NT server serves as the 
SQL server as well. This server is part of the NDS 
development lab, and as such is available to all KSC 
users for development and operational use. 

The primary user’s screen is shown in Figure 7. Note 
that the screen is split into two sections -- the 
DEVICE/USER INFORMATION section and the 
ADDRESS INFORMATION section. The 

DEVICE/USER part of the screen looks at data in the 
file containing device/user information while the 


The network and subnet values allowed for a given 
addition are controlled by the table shown in Figure 8. 
After the building and room have been selected, the IP 
Address' screen appears with the “Network” and 
“Subnet” fields automatically filled with data from the 
table. When moving to the ADDRESS side of the 
screen, the TCP/IP Addr fields will contain the 
appropriate network and subnet data. The user will not 
be able to change these three octets. 

The user can either enter a number in the last TCP/IP 
Addr block or click on the S/M hand icon. If a number 
is manually entered, it is compared against the IP 
Address database. If a duplicate is found, an error 
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screen appears showing details about that number. The 
user then can manually select a new number, or let the 
application automatically assign the next available 
number. 

NETWORK DRAWINGS AND DATABASE 
Another significant recent development concerns the 
marriage of detailed facility and network drawings to 
database information. This effort was performed by the 
Shuttle Processing Data Management System (SPDMS) 
engineers. SPDMS is part of the SODN organization’s 
network. 

The design for this documentation system includes 
electronic access to facility drawings that originate on 
the NASA DE VAX host computer. Facility drawings 
are prepared using Intergraph’s MicroStation 
CAD/CAE drawing package. These facility drawings 
are copied to the master PC workstation that has been 
established as the authoritative source of cabling as- 
builts. This workstation is then used to provide the line 
contractors with a referenced facility drawing, seed file, 
and individual database tables of that facility. The line 
contractors can then document their additions, changes, 
etc. In addition to the CAD drawing, individual 
database records can be linked to any picture element 
within the drawing. This allows for database records to 
be displayed by simply selecting the element. For KSC- 
wide reference, the master PC workstation is used as a 
staging area for the completed drawings and data that 
can then be copied to the network directories on the 
NASA DE VAX host. In addition, through a series of 
conversions, the drawing can also be placed on the IBM 
host. Anyone capable of using an IBM host session on 
an OS/2 workstation can ‘view’ the network drawing. 

The network configuration for this part of the 
documentation project is shown in Figure 9. Central to 
the operation of this system is the Master PC 
Workstation. This workstation not only uses Intergraph 
MicroStation for working with the drawings on a local 
level but also provides a means for tracking, 
configuration, and control of SPDMS network data. 
Detailed network design information is then added to 
the facility drawings to yield a complete network 
documentation package. A fixed format network 
drawing is brought up on the users screen. Clicking on 
a network element brings up the database file 
information concerning that element. A sample network 
drawing is shown in Figure 10. The left half of the 
figure shows the full floor of the facility being worked. 
The right half is a detail section of the left view. To 
determine more about any shown element, the user 
moves the arrow over the element of interest and double 


clicks the left mouse button. A table containing detailed 
information about the selected element appears as 
shown in Figure 1 1 . 



Figure 9. SPDMS NDS Network Configuration. 



Figure 10. MicroStation Network Drawing. 


At this point, we have shown several applications that 
are specific to a particular part of the total 
documentation picture. What is ultimately desired is to 
be able to electronically identify a single network 
element on a screen and from that view manipulate data 
concerning the complete ‘circuit.’ Thus, if a network 
problem occurs, an engineer can bring up a screen that 
allows him to pick a known element within the problem 
area and subsequently view the documentation and 
database information for the circuit from the user device 
to the host device. The preliminary design for this has 
been started. Typical of the engineer’s initial screen is 
shown in Figure 12. This application was launched by 
the user having clicked on the Ckt. Tracking button of 
the main menu. As stated earlier, the form of this screen 
could vary to meet user needs while the function 
remains basically as shown. Each of the buttons shown 
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Figure 11. Figure 10 With Added Record From 
Database. 



Figure 12. Cable Tracking Menu. 
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Figure 13. Typical Data View. 


represent a part of a typical network path or circuit. 
Using the mouse to click on one of the buttons brings 
another screen in view. The new screen contains 
information from the database and shows the to and 
from data for the element selected. The information 
shown can be viewed or, if access privileges are 


sufficient, data can be modified. A typical screen is 
shown in Figure 13. Note that the user has a number of 
available functions that can be performed by clicking on 
the appropriate button. 

One of the nice features of this application is that the 
user, from any detail screen, can click on the View Ckt 
button and obtain a screen similar to that shown in 
Figure 14. This pictorial view shows the complete 
network circuit from end-to-end for the circuit selected. 
In addition, clicking on an element in this view brings 
up an overlaying table with the pertinent detail 
information about that part of the circuit. Of course, 
some end-to-end circuits will contain fewer elements 
than those shown in Figure 14. This application is 
being developed on a PC platform using Visual Basic. 
The drawing components are icons representing the 
elements shown and placed in the proper sequence. 
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Figure 14. End-to-End Circuit Drawing. 


INTERNET USE 

Another aspect of the documentation effort that can’t be 
covered in detail here is using the Internet and a viewer 
like Mosaic or Netscape to view and modify network 
data. Lockheed, Intergraph, and I-NET engineers have 
developed a preliminary system that uses a number of 
off-the-shelf products for developing what is currently 
called the FasTrack application. This application was 
designed to handle service requests where the required 
network resources are available. Use of standard 
desktop (Windows) components such as Microsoft 
Office, etc., allows development without having to 
procure specialized or expensive software. Intergraph’s 
suite of-.new database products for the PC is used 
extensively. Workstation components needed to run this 
application add a small cost per workstation. 
Everything else needed is already installed on the 
workstation. 

FasTrack data is contained in a database located 
physically on a UNIX server. Access to the database is 
controlled using Intergraph’s Network File Manager 
(NFM) product. Full security is thus maintained by the 
setup parameters of NFM for the database. Using 
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Mosaic or Netscape to access the application lets all 
platforms that support Mosaic or Netscape view and, in 
some cases, modify the database. The initial user screen 
is shown in Figure 15. The menu shown is actually a 
Microsoft PowerPoint slide. 



Figure 15. Netscape Screen for Access to the 
Database. 


Future enhancements will extend current developments 
to function across multiple computer platforms with no 
apparent difference to the user. This will be 
accomplished within the constraints of the individual 
platforms in use. 


SUMMARY 

In summary, this paper touched on a few of the 
applications developed to process network 
documentation data. Several additional modules are 
available to the user that were not discussed here 
because of space limitations. Feasibility of designing 
GUI frontend modules to maintain existing network 
design data having various forms and locations has been 
demonstrated. As additional development is completed, 
the benefits of these efforts provide a consistent and 
standardized approach for working with network design 
data. Important to this effort is the concentration on 
design efforts that utilize existing computer hardware 
and software and minimize development time by using 
state-of-the-art visual design tools. 
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